Skip to content

Reuse the original live thread for project result readback - #8247

Merged
loopx-agent merged 1 commit into
mainfrom
codex/live-result-review-observation-20261107
Nov 7, 2026
Merged

loopx-agent merged 1 commit into
mainfrom
codex/live-result-review-observation-20261107

Conversation

@loopx-agent

Copy link
Copy Markdown
Collaborator

Goal And Delivered Outcome

  • The original private-project worker already has a live Codex process when it checks a completed partial result. If that result cannot authorize writable continuation, the baseline starts a second native reader. It also tries that reader when the live adapter's thread no longer matches the original, which can reserve a result review against the wrong current owner.
  • Reuse the exact live thread for evidence when its inventory is stable and no active or background work is owned. Open the persisted-history reader only when there is no current adapter. The existing restricted result-review Turn remains separately sandboxed and goes through the original source, queue and dispatch checks.
  • Intended base is main. This is scoped to ordinary private-project recovery.

Author Declaration

  • Written by: model_agent | GPT-6 | OpenAI

Implemented against

  • Specification and revision: docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md at ebb39f4db088cc77927c4514d614476ad0a5c84e.
Criterion Disposition Symbol / path Validation
Explicit unfinished work after a completed Turn implemented ChatExternalConversations.recover_failed_request Existing writable restart, source and native-effect tests
Completed private project result reviews implemented recover_failed_request, completed_result_review_readback Live proof, cold-only fallback, unmatched thread hold and idempotent original return

Scope And Continuation

  • Read-only review can inspect existing results while original work remains pending. The previous partial answer, unknown effects and original delivery remain in the original records. Deployment and natural historical message recovery are separate acceptance steps.

Validation

  • Tested revision: fa35f01a377f08502955beac2e6c5176b7e7357b
  • Run state: finished
  • Input classes: synthetic, public_fixture
Check kind Result Public-safe evidence / limitation
real_entrypoint passed All 24 recovery cases through the existing Feishu handler with synthetic provider and native fixtures. Positive review cases return one verified reply with unchanged original bytes and artifacts. Invalid or foreign live proof cannot reserve a review.
regression_parity passed Identical updated tests on immutable main and the candidate. The base passes 17 and fails 7 as expected. Four live reviews launch one avoidable native reader on the base, two held inputs probe unnecessarily, and a foreign live owner can reserve a review. The candidate passes all 24.
integration passed 237 cases across Chat conversation binding, native history and interrupted steward answers.
real_backend passed Codex CLI 0.166.0-alpha.5.1 in a synthetic workspace with isolated native state. The actual app-server resumes the same thread with the verified workspace-only read profile. No model Turn requested.
static passed Exact-head local premerge checks, Ruff, public boundary and bilingual RFC parity.
  • Coverage and gaps: Provider delivery in the matrix is synthetic. Production installation and independent original-audience readback are tracked separately.

Frontend / Visual Evidence

  • UI impact: none. The change selects the native reader inside the background recovery path.

Type of Change

  • Bug fix
  • Documentation update
  • Test update

LoopX Area

  • Control plane (goals, todos, quota, scheduler, registry, runtime)

Shared-authority RFC fixture impact

  • N/A. Recovery uses the existing Core plan and persisted state contract.

Boundary Checklist

  • Public-safe diff and description.
  • Scoped to ordinary private project recovery.
  • Both RFC languages and exact-head premerge check.
  • UI impact marked none.
  • DCO trailer included.

Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer: model_agent | GPT-6 | OpenAI | self_reported

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机 / Motivation

飞书普通项目原请求收到部分答复后,原服务会核对能否继续剩余工作,或者只读查看已有产物并补答。 旧路径在原 Codex 进程仍持有该线程时,也另外启动一个原生进程读历史。原线程已经不匹配时,旧路径还可能预留一次复核。 新路径从同一个可核验的原生进程读回结果。相同测试在主干有 7 项失败,本提交 24 项通过。 本次只调整项目结果复核的证据读取。已入队续办、业务完成与生产原消息补答分别验收。

改动思路 / Approach

由现有 Core 恢复入口选择读取方式,复用原生结果读取函数。原工作进程持有匹配线程时直接读取,只有会话没有 adapter 时才读持久化历史。 这份读回只证明原答复和未完声明,实际只读复核另由原队列和当前授权决定。 现有原生读取继续校验原始最终答复、未完声明和后来可关联的输入。已有后台工作、原线程不同或原生证据缺失时,保留待处理状态。真正派发只读复核时还要重新核对授权、队列和原生结果。

具体改动 / Changes

关键代码讲解

  • 原恢复入口把项目可写续办和结果复核的观察放在同一分支。能证明效果的仍是原可写进程。需要核对结果时,仅复用匹配且无后台工作的原进程。 恢复入口
  • 结果读回函数验证完整、稳定的原生记录,核对原始最终答复及可关联的后续输入。没有原 adapter 时由原持久化读取路径提供同一种结果证据。 原生读回
  • 原派发检查保留当前绑定、来源、排队和停止门。实际复核只能沿原线程使用工作区只读权限,网络关闭。五个复核用例均核对旧回执、原文件和一次独立回复。 派发校验 对账测试
基线 RFC 条款 结论 验证
Explicit unfinished work after a completed Turn implemented 原可写续办、重启、排队变化及效果核验继续通过
Completed private project result reviews implemented 原进程、冷读、外来线程、独立只读权限和原消息回执

逐条按基线的两个条款核对。 基线 RFC

对主干的风险 / Risks

主要风险是把可写进程的读取当成可写授权,或让不同线程的历史被误用。现有原生结果检查只读取已知记录,实际只读复核由原队列及独立沙箱执行。新测试记录了每次启动、同一线程、只读目录、无网络和原文件不变,也检查了来源修改、撤权和停止。相同用例主干通过 17 项、本提交通过 24 项。另有 237 项相邻回归和本地合并前检查通过。

我的整体评价 / Verdict

批准这次读回修复。它去掉原服务在已有可用进程时的额外读取进程,也避免给不匹配的现有线程预留复核。检查的是后台对账和权限核验,界面、回执格式和正文呈现无需视觉对照。 实际 Codex 宿主接回同一隔离线程并报告受限权限,飞书补答与旧业务补办仍需原受众读回。

English verdict: APPROVE fa35f01. Exact-head checks verify original live-thread readback, cold fallback on absence, restricted result-only review and unchanged original delivery. Production historical recovery remains separate.

@loopx-agent
loopx-agent merged commit 8e86f17 into main Nov 7, 2026
20 of 26 checks passed
@loopx-agent
loopx-agent deleted the codex/live-result-review-observation-20261107 branch November 7, 2026 06:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant